home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9610 / 000021_owner-urn-ietf _Wed Oct 9 05:13:28 1996.msg < prev    next >
Internet Message Format  |  1997-02-19  |  5KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA15667 for urn-ietf-out; Wed, 9 Oct 1996 05:13:28 -0400
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA15662 for <urn-ietf@services.bunyip.com>; Wed, 9 Oct 1996 05:13:25 -0400
  3. Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA24003  (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 05:13:23 -0400
  5. Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16360(2)>; Wed, 9 Oct 1996 02:13:17 PDT
  6. Received: by golden.parc.xerox.com id <2765>; Wed, 9 Oct 1996 02:13:03 PDT
  7. To: michaelm@internic.net
  8. Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com
  9. In-Reply-To: <325A5C0C.5D13@internic.net> (message from Michael Mealling on
  10.     Tue, 8 Oct 1996 06:50:04 PDT)
  11. Subject: Re: [URN] advantages of NAPTR over PURLs
  12. From: Larry Masinter <masinter@parc.xerox.com>
  13. Message-Id: <96Oct9.021303pdt."2765"@golden.parc.xerox.com>
  14. Date: Wed, 9 Oct 1996 02:13:03 PDT
  15. Sender: owner-urn-ietf@services.bunyip.com
  16. Precedence: bulk
  17. Reply-To: Larry Masinter <masinter@parc.xerox.com>
  18. Errors-To: owner-urn-ietf@bunyip.com
  19.  
  20. > The only way to do this is with a new record. That record is the
  21. > SRV record which a lot of people are planning on using. A records
  22. > only have the IP address, nothing else.
  23.  
  24. Presumably if you have SRV records, you could use them for HTTP
  25. servers too, including http://www.purl.org. So the fact that this is a
  26. general mechanism means that 'priority' is no longer an advantage of
  27. NAPTR vs. PURL.
  28.  
  29. > No. It has to do with the allowable packets size for DNS via UDP.
  30. > If it goes over then the packet is truncated causing the client
  31. > to have to reconnect via TCP. IF the part that is truncated
  32. > though is in the additional information field then the user
  33. > is NOT given an error. This is a problem with DNS that
  34. > cannot be fixed. Even if you consider it a problem....
  35.  
  36. I'm really confused why long A records are a problem and long SRV
  37. records aren't a problem, but I suppose I can take your word for it.
  38.  
  39. > Because it has "purl.org" in it which is OWNED by OCLC. They pay the
  40. > bill. As far as the NIC is concerned they can do with it whatever
  41. > they want and we can't do squat about it. NAPTR should eventually
  42. > be a TLD all its own that is not 'owned' by anyone but the IANA (which
  43. > has its own problems but I won't go into that).
  44.  
  45. Look, every place I've said "purl.org", change it to "purl.net" and
  46. register "purl.net" in a standards track document, 'owned' by IANA.
  47.  
  48. If you did that, what would distinguishes 'urn.net' and 'purl.net' in
  49. terms of longevity?
  50.  
  51. > Because we don't to be tied to DNS. The URN framework (not NAPTR)
  52. > works in all situations no matter if you have DNS or not. You
  53. > can run the service in an OSI world using X.500 (everyone scream).
  54.  
  55. I'm sorry, I was trying to establish the advantage of the NAPTR
  56. implementation against the PURL implementation of URNs, not against
  57. the 'framework'.
  58.  
  59. > 1) Areas of Authority. purl.org is authoritative for everything. I doubt
  60. >    if that scales. If its not authoritative how do I find the authoritative
  61. >    server?
  62.  
  63. Who is the authority of "urn.net"? The authority for purl.net can be
  64. delegated in the same way that NAPTR delegates the authority for
  65. urn.net.
  66.  
  67. > 2) Services. I don't want just the URL. I want a URC. But I want it in
  68. >    SGML and not MARC. How can I get that out of a PURL?
  69.  
  70. This is really speculative, of course, since there's never quite been
  71. agreement on exactly what a 'URC' might be. But I'd conjecture that
  72. the way you get something out of a resource other than the resource
  73. itself is by applying some other method than GET.
  74.  
  75. > 3) Other available protocols. The PURL doesn't tell me what other
  76. >    protocols are available and which one it considers the best.
  77.  
  78. If the 303 response from HTTP includes multiple Location: results, you
  79. could pick the one you liked the best. It's true that the results
  80. don't rank order them, but is that actually practical?
  81.  
  82. > 4) Equivalence. How do I match equivalence? Do I just match on
  83. >    the part after the hostname? If so then authority areas cannot
  84. >    exist. If not then your protocol is indistinquishable from the
  85. >    rest of the authority area. 
  86.  
  87. I'm not sure where the 'equivalence' requirement came from, since it
  88. was specifically not a URN requirement. It wasn't a URN requirement
  89. primarily because it was considered impossible.
  90.  
  91. > There is not ONE killer reason why the URN framework is better than
  92. > PURLs. There are alot of smaller ones....
  93.  
  94. I think you misunderstood: I'm not questioning the 'URN
  95. framework'. I'm questioning the NAPTR implementation of the framework.
  96. I'm dubious about these DNS records with 'dblookup+N2C' in the middle
  97. of them and the idea that just because the syntax is embedded in DNS
  98. as a transmission mechanism that it isn't a 'protocol'.
  99.  
  100. Larry
  101.  
  102.  
  103.